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ABSTRACT 

Botnet-based  hosting  or  redirection/proxy  servtees  provide 
botmasters  with  an  ideal  platform  for  hosting  malicious  and 
illegal  content  while  affording  them  a  high  level  of  misdirec¬ 
tion  and  protection  Because  of  the  unreliable  connectivity 
of  the  constituent  bots  (typically  compromised  home  com¬ 
puters),  domains  built  atop  botnets  require  frequent  updates 
to  their  DNS  records,  replacing  the  IPs  of  offline  bots  with 
online  ones  to  prevent  a  disruption  in  (malicious)  service 
Consequently,  their  DNS  records  contain  a  large  number  of 
constantly  ^changing  (i.c..  “fluxy")  IPs.  earning  them  the  de¬ 
scriptive  montker  of  fast-flux  domains — or,  when  both  the 
content  and  name  servers  are  fluxy,  double  fast-flux  domains. 
In  this  paper,  we  study  the  global  lP-usage  patterns  exhib¬ 
ited  by  different  types  of  malicious  and  benign  domains,  in¬ 
cluding  single  and  double  fast-flux  domains.  We  have  de¬ 
ployed  a  lightweight  DNS-probing  engine,  ealled  DIGGER , 
on  240  PlanctLab  nodes  spanning  4  continents.  Collecting 
DNS  data  for  over  3.5  months  on  a  plethora  of  domains, 
our  global  vantage  points  enabled  11s  to  identify  distinguish¬ 
ing  behavioral  features  between  them  based  on  their  DNS- 
query  results.  We  have  quantified  these  features  and  demon¬ 
strated  their  effectiveness  for  detection  by  building  a  proof- 
of-coneept.  multi-leveled  SVM  classifier  eapahlc  of  discrim¬ 
inating  between  five  different  types  of  domains  with  mini¬ 
mal  false  positives.  We  have  also  uncovered  new,  caulious 
IP-managcmcnt  strategies  currently  employed  by  criminals 
to  evade  detection.  Our  results  provtde  insight  into  the  cur¬ 
rent  global  state  of  fast-flux  botnets,  including  the  increased 
presence  of  double  fast-flux  domains  and  their  range  in  im¬ 
plementation  In  addition,  we  discover  potential  trends  for 
botnet-based  services,  uncovering  previously-unscen  domains 
whose  name  servers  alone  demonstrate  fast-flux  behavior. 

1.  INTRODUCTION 

A  botnet  is  a  vast  collection  of  compromised  computers 
under  the  control  of  a  botmaster  utilizing  a  Command-and- 
Control  (C&C)  infrastructure.  By  exploiting  Tntemet  Re¬ 
lay  Chat  (IRC),  pccrrto-pccr  (P2P),  and  other  protocols  as 
flexible  and  extensible  means  for  C&C,  botnets  have  gained 
a  great  deal  of  versatility  in  providing  malicious  services 
and  generating  illicit  profit.  Among  the  numerous  criminal 
uses  of  botnets,  one  of  the  more  advantageous  is  the  botnet 
based  hosting  service,  which  proxies  or  redirects  unsuspect¬ 
ing  users  to  illegal  or  nefarious  content.  Since  botnets  arc 
essentially  an  abundant  source  of  disposable  IPs,  they  can 


easily  he  turned  into  a  large  network  of  redirection/ proxy 
servers  pointing  to  malicious  content  hosted  elsewhere — on 
anything  from  a  powerful  central  server  to  another  bot. 

Used  as  a  misdirection  mechanism  for  evading  detection, 
botnet-based  hosting  services  often  come  in  tandem  with  a 
variety  of  other  criminal  scams,  constituting  an  essential  por¬ 
tion  of  botnets’  overall  operation  For  example,  spam/phishing 
campaigns  often  utilize  botnets  for  misdirection.  They  be¬ 
gin  by  using  some  spamming  mechanism  to  send  seemingly 
interesting  phishing  emails  embedded  with  innocuously  dis¬ 
guised  links  whose  domain  names  resolve  to  IP  addresses 
of  compromised  computers  in  a  botnet.  Once  victims  click 
the  embedded  links,  they  connect  to  the  bots,  which  then 
redirect  them  to— or  serve  as  proxies  for — the  host  of  the 
nefarious  content  This  strategy  grants  criminals  a  high  level 
of  anonymity  while  enabling  easy  and  centralized  manage¬ 
ment  of  the  malicious  content  However,  because  botnets  arc 
composed  primarily  of  compromised  home  computers  with 
unreliable  connectivity,  it  is  not  uncommon  for  them  to  un- 
predietably  go  offline  (e.g..  the  computer  is  turned  off  or  the 
installed  malware  is  discovered  and  removed).  Botnet-based 
hosting  services,  therefore,  must  be  protected  against  the 
failure  or  disruption  of  individual  bots,  ensuring  the  avail¬ 
ability  and  stability  of  the  hosted  scrvicc/content  As  a  re¬ 
sult,  they  adopt  fast-flux  (FF)  DNS  techniques,  which  fre¬ 
quently  change  the  domain-name  mappings  to  different  bots' 
IP  addresses.  When  the  victim  tries  to  visit  the  malicious 
domain,  the  DNS  server  responds  w  ith  a  set  of  up-to-date, 
active  bot  IPs  By  recruiting  a  large  pool  of  IPs  and  sup¬ 
plying  a  large  number  of  IPs  per  query,  botmasters  can  en 
sure,  with  high  probability,  that  the  malicious  domain  re¬ 
solves  to  an  online  bot*s  IP  An  additional  level  of  control 
and  resilience  is  attained  by  giving  the  domain’s  IP  map¬ 
pings  a  short  time-to-live  (TTL)  value,  allowing  botmasters 
to  quickly  replace  offline  bots.  Using  this  FF  technique,  bot¬ 
masters  effectively  turned  their  botnets  into  a  global  Content 
Delivery  Network  (CDN),  providing  highly  available  and 
reliable  content-hosting  services  despite  frequent  node  fail 
urcs/disconnectivity  This  extends  the  lifetime  of  illegal  ac¬ 
tivities  the  botnets  provide,  complicating  disruption  efforts 
hy  introducing  an  additional  layer  of  misdirection. 

Previous  research  focused  on  the  features  of  FF  botnets 
and  their  malicious  uses  in  phishing  scams  [14]  (e.g  ,  Storm 
Worm  and  Rock  Phish)  However,  little  has  been  reported  on 
botnets’  IP-usage  behavior  from  a  global  perspective.  Be¬ 
cause  botnets  are  formed  with  myriad  compromised  hosts 
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dispersed  around  the  world,  accurate  characterization  of  how 
botmasters  manage  this  vast  number  of  IPs  can  only  be  achieved 
by  collecting  and  analyzing  data  from  a  global  perspective. 

In  this  paper,  we  attempt  to  achieve  this  goal  and  explore  the 
global  usage  patterns  of  botnets’  IP  addresses.  The  contribu¬ 
tion  of  our  work  is  four-fold.  First,  we  build  a  global  query 
engine  called  DIGGER  that  monitors — for  an  extended  pe¬ 
riod  of  time — complete  DNS  behavior  from  240  geographically- 
dispersed  vantage  points  spanning  four  continents.  This  pro¬ 
vides  us  with  a  global  view  of  how  different  types  of  do¬ 
mains  vary  in  their  IP-usage  patterns.  Second,  we  propose 
effective  methods  to  characterize  and  quantify  the  temporal 
and  spatial  IP-usage  patterns  of  FF  botnet  domains,  facilitat¬ 
ing  the  classification  and  detection  of  different  domain  types. 
This  also  allows  us  to  reveal  several  prcviously-unknown 
features  of  FF  botnets  and  uncover  new,  discreet  IP-managcmcnt 
strategies  currently  employed  by  criminals  to  evade  detec¬ 
tion.  Third,  we  design  and  implement  a  proof-of-conccpt 
classiher  based  on  a  multi-leveled  machine  learning  algo¬ 
rithm.  Utilizing  the  behavioral  features  of  a  domain’s  IP 
usage,  the  classifier  accurately  and  automatically  identifies 
different  types  of  malicious  and  benign  domains.  Finally, 
we  apply  the  classifier  on  more  than  three  months’  worth  of 
globally-collected  data.  The  results  demonstrate  the  current 
trend  of  FF  botnets  and  the  effectiveness  of  using  the  dis¬ 
tinguishing  behavioral  features  we  identified  with  our  global 
DNS-monitonng  system 

The  remainder  of  this  paper  is  organized  as  follows.  Sec¬ 
tion  2  discusses  related  work.  Section  3  defines  the  termi¬ 
nology  we  use.  Section  4  explores  the  global  DNS  IP-usage 
patterns  for  different  domain  types.  Section  5  presents  our 
proof-of-conccpt  classifier  and  its  experimental  evaluation 
results.  Section  6  discusses  the  limitations  of  our  system  and 
our  future  work,  and  finally.  Section  7  concludes  the  paper. 

2.  RELATED  WORK 

Researchers  have  focused  on  the  operations  and  threats 
of  botnets  by  collecting  and  analyzing  bot-rclatcd  activities, 
such  as  IRC  traffic  [17|.  spam  emails  |22].  and  DNS  queries 
[18].  For  example,  Rajab  et  al  [1 7]  constructed  a  distributed 
infrastructure  to  measure  IRC  botnet  activities  and  showed 
that  botnets  contribute  the  majority  of  unwanted  traffic  in 
the  Internet.  Gnzzard  et  a /  [6]  analyzed  the  architecture  and 
communication  protocol  of  a  most  recent  P2P  botnet,  Pca- 
coin  (a.k.a  Storm  Worm)  [5],  demonstrating  that  P2P  bot¬ 
nets  arc  more  rohust  to  node  failures  and  difficult  to  take 
down  All  these  methods  fall  into  the  category  of  passive 
analysis.  To  gain  a  botnet’s  insider  view,  researchers  also 
took  active  approaches,  infiltrating  botnets  with  actual  mal¬ 
ware  samples  or  customized  crawlers.  For  example,  Holz 
et  al.  [12]  crafted  a  specific  P2P  client  to  join  the  Storm 
Worm's  P2P  botnet  and  analyzed  its  in-depth  features.  More 
recently.  Stone-Gross  et  al  [20]  successfully  took  over  the 
Torpig  botnet  for  10  days  by  preemptively  registering  DNS 
domains  the  hots  would  he  contacting  as  C&C  servers  in  the 


near  future,  allowing  them  to  reveal  detailed  operations  of 
the  botnet  and  accurately  estimate  the  number  of  compro¬ 
mised  hosts. 

Because  of  the  signilieant  threats  botnets  have  posed  to  In¬ 
ternet  services  and  applications,  researchers  have  proposed 
various  botnet  detection  approaches.  Some  exploit  the  net¬ 
work  behavior  typical  of  botnets’  C&C  protocols.  For  exam¬ 
ple,  BotHuntcr  [8]  attempts  to  detect  bots  using  IDS-driven 
dialog  correlation  based  on  IRC  C&C  communication  and 
other  common  actions  taken  during  the  life  cycle  of  a  bot. 
BotSniffer  |9]  identifies  HTTP-  and  lRC-based  C&C  chan¬ 
nels  by  capturing  the  coordinated  and  synchronized  commu 
nication  patterns  in  the  C&C  traffic.  To  eliminate  the  re¬ 
liance  on  IRC-  or  HTTP-based  C&C  protocols,  Gu  et  al. 
proposed  BotMincr  [7],  which  clusters  similar  communica 
tion  and  malicious  traffic  and  performs  cross-cluster  eorre 
lation  to  identify  bot-infcctcd  hosts. 

Another  common  method  for  botnet  detection  is  identi¬ 
fying  the  unique  network  patterns  of  scams  they  perpetrate. 
Among  die  numerous  criminal  uses  of  botnets,  their  use  as 
hosting  or  redirection/proxy  servers  for  illegal  content  and 
phishing  scams  prov  ides  an  ideal  platform  for  financial  gain 
However,  because  of  the  unreliable  nature  of  bots,  more  bot¬ 
masters  have  adopted  fast- 11  ux  DNS  techniques  to  ensure  the 
availability  and  stability  of  their  malicious  scrviec/eontcnt. 
FF  techniques  were  first  reported  and  analyzed  as  pail  of 
the  HoncyNet  project  [21].  Holz  et  al.  [II]  and  Passenm 
et  al.  [15]  both  studied  the  characteristics  of  FF  networks 
and  developed  detection  algorithms.  They  gathered  URL 
domains  from  spam  emails  and  monitored  their  DNS-query 
results  for  an  extended  period  of  time,  extracting  a  set  of 
unique  features  such  as  number  of  unique  IPs,  numher  of 
ASes,  lifetime  of  the  domains,  TTl.  values,  etc.  A  linear  de¬ 
cision  function  [  1 1 1  and  a  naive  Bay  esian  classifier  ( 1 5]  were 
applied  on  these  features  to  identify  FF  networks.  Nazario 
and  Holz  [14]  later  applied  a  similar  approach  to  track  the 
use  of  FF  domains  and  characterize  additional  properties  of 
FF  botnets,  including  their  member  size,  lifetime,  and  top- 
level  domain  distribution  Their  results  demonstrated  that 
continuous  data  mining  of  FF  DNS  records  can  yield  insights 
into  the  operations  of  FF  botnets.  More  recently,  Konte  et 
al. [13]  studied  the  dynamics  of  the  FF  network  from  the 
perspective  of  online  scam  hosting  infrastructures  for  dif¬ 
ferent  spam  campaigns,  measuring  the  change  rates  of  DNS 
records,  distribution  of  TTL  values,  and  location  of  IP  ad¬ 
dresses.  Their  measurement  results  suggested  that  some  per¬ 
sistent  features  may  be  useful  in  the  detection  of  FF  hotnets. 

Our  work  is  unique  and  different  from  this  previous  work 
as  follows.  First,  all  of  the  previous  wrork  collected  data  from 
a  single  vantage  point,  and  henec,  may  fail  to  capture  useful 
features  that  can  only  be  discovered  from  a  global  perspec¬ 
tive  (c.g  ,  different  IP-advcrtiscment  strategies  used  by  FF 
networks,  CDN  and  non-CDN  domains)  By  contrast,  we 
deployed  a  large  number  of  sensors  around  the  world,  pro¬ 
viding  a  global  perspective  of  IP-usage  patterns  for  differ- 


cm  types  of  FF  botnets  (in  particular,  double  FF  domains). 
Second,  both  approaches  in  [11]  and  [15]  separate  FF  do¬ 
mains  indiscriminately  from  normal  domains  without  distin¬ 
guishing  their  types  (e.g.,  single  and  double  FF  networks). 
In  this  paper,  we  provide  detailed  categorization  of  FF  do 
mains  (including  two  types  of  single  FF  networks  and  a  dou¬ 
ble  FF  network)  and  developed  a  multi-level  classifier  capa¬ 
ble  of  discriminating  between  different  types  of  both  FF  and 
non-fluxy  domains.  This  finer-grained  classification  allows 
us  to  gain  insight  into  the  current  state -of-art  and  potential 
trends  of  different  FF  botnets,  as  well  as  their  range  in  im¬ 
plementation.  Moreover,  to  create  an  elfieicnt  classifier  with 
minimal  false  positives/negatives,  we  carefully  selected  and 
quantified  7  distinguishing  features  (some  were  reported  pre¬ 
viously  [11,  15,  13]  but  others  are  new)  and  apply  a  subset 
of  features  at  each  level  of  our  classifier.  Third,  because  the 
purpose  of  using  FF  botnets  is  to  reliably  distribute  mali¬ 
cious  content  to  users  despite  bot  failures,  the  DNS  behavior 
of  FF  botnets  resembles  that  of  traditional  CDNs  [4]  cm 
ploying  DNS  techniques  for  load-balancing.  As  a  result, 
some  features  used  in  the  previous  work  (e.g.,  TTL  values, 
lP-change  rate,  number  of  unique  IP  addresses  and  ASes) 
appear  similar  between  FF  and  CDN  domains,  potentially 
leading  to  false  positives.  In  this  paper,  we  conduct  a  com¬ 
parative  analysis  of  different  IP-management  schemes  used 
in  FF  botnets  and  popular  CDNs.  This  allows  us  to  accu¬ 
rately  filter  CDN  domains  beforehand,  and  thus,  minimize 
the  false  positives  of  the  classifier. 

3.  TERMINOLOGY 

This  section  defines  the  terminology  we  have  adopted  for 
succinctness  and  clarification  when  discussing  the  various 
domain  types  and  DNS  records  in  this  paper.  The  primary 
DNS  record  components  we  consider  are  defined  in  Table  I . 


A  rec 

•  he  address  (Al  recora  n  a  ONS  query  on  a  con-air 

•  The  IP  adoresses  of  t^e  domain  s  con-en-  servers. 

NS  rec 

•  The  t  JTie  server  (NS)  eecotc  in  a  DNS  query  on  a  domam 

•  The  domain  names  {not  IP  adressev  of  the  domain's  NSes 

NArec 

•  The  A  rec  n  a  DNS  queryon  a  aoma  n's  name  serve's 

•  The  IP  addresses  of  :-e  domain  s  NSes 

•  The  result  of  a  DNS  ouery  recuest  for  an  IP  s  domam  name 

Reverse  ONS 

(i  e  ,  PTR  request) 

lookup/name 

•  When  performing  a  DNS  query  cm  »  oomjii,  we  also  do  * 

reverse  DNS  ockup  on  the  domain  s  A  and  NA  rec  Ps 

Table  1:  DNS  record  terminology 

In  Fig.  I,  we  have  plotted  the  global  IP  usage — as  seen 
from  the  DNS  queries — for  some  representative  domains  of 
the  different  domain  tv  pcs.  In  this  figure,  the  Time  axis 
represents  the  time  (in  seconds)  since  our  distributed  DNS 
query  engine  (DIGGER,  Section  4.2)  was  deployed.  Node 
Index  represents  the  node  (from  those  dispersed  around  the 
globe)  that  the  IP  was  observed  on,  with  positive  values  in¬ 
dicating  an  A  rcc  IP  and  negative  values  an  NA  rce  IP,  IP  In¬ 
dex  is  a  unique  index  incrementally  assigned  to  each  newly- 


observed  IP  In  what  follows,  we  explain  the  terms  we  use  to 
describe  these  various  domain  types  and  how  they  behave. 
Their  global  behavior  will  be  explained  further  in  Section  4. 

FF  domains  are  malicious  domains  utilizing  a  fast- flux 
(FF)  DNS-advertisement  strategy,  typically  built  atop  bot¬ 
nets.  Because  hots  may  unexpectedly  go  offline.  FF  do¬ 
mains  advertise  numerous  IPs  in  their  DNS-qucry  results, 
helping  ensure  some  of  the  IPs  belong  to  a  functional  bot 
The  TTL  of  the  IPs  used  by  FF  domains  tend  to  be  relatively 
short;  this  permits  the  botmasters  a  finer  level  of  control  in 
replacing  IPs  advertised  to  the  DNS  servers,  increasing  the 
availability  of  an  online  bot  and  access  to  the  malicious  pay- 
load.  It  is  this  excessive  number  of  constantly-changing  IP 
addresses  that  qualifies  a  domain's  DNS  records  and  adver¬ 
tisement  strategy  as  ~fluxy'\  and  the  domain  is  considered  a 
FF  domain  Domains  exhibiting  FF  behavior  in  only  a  sin¬ 
gle  record  type  (i.e.,  A  rec  or  NA  rec,  but  not  both)  are  eon 
sidered  FFxl  domains  (single  fast  flux).  More  specifically 
FFxl  domains  that  are  fluxy  in  their  A  rocs  (i.e..  content 
servers)  are  termed  FFxl_Arec  domains,  while  those  thai 
are  fluxy  in  their  NA  rees  (i.e..  name  servers)  are  termed 
FFxl_NArec  domains;  FFxl_NArec  domains  arc  able  to 
evade  current  detection  strategies  that  focus  on  A  rees  by 
migrating  their  fluxy  behav  ior  to  their  NA  rees,  where  it  is 
less  likely  to  be  noticed.  When  FF  domains  are  flux)  in  both 
their  A  and  NA  rees,  they  are  considered  double  fast  flux  or 
FFx2  domains.  A  FFx2  domain  can  provide  unprecedented 
control  in  the  management  of  the  domain  and  its  resources 
botnet  or  otherwise  with  the  DNS  service,  affording  the 
botmaster  a  high  level  of  misdirection  and  protection. 

CDN  domains  are  valid,  benign  domains  that  uses  a  CDN, 
such  as  Akamai,  to  improve  the  delivery  of  their  content. 
CDNs  -consisting  of  a  system  of  computers  networked  to¬ 
gether  for  the  purposes  of  improving  the  performance  and 
scalability  of  content  distribution  produce  DNS-query  re¬ 
sults  resembling  those  of  malicious  FF  domains:  numerous, 
changing  IPs  per  query  with  short  FrL  values.  This  affin¬ 
ity  is  a  consequence  of  their  similar  goal  to  provide  roll 
able  content  delivery  despite  node  failure,  as  well  as  their 
shared  assumption  that  any  node  can  temporarily  or  perma¬ 
nently  fail  at  any  time  However,  CDN  domains  demon¬ 
strate  geographic  awareness  (i.e.,  IPs  geographically  close 
to  a  DNS  server  will  be  advertised  with  higher  probability  at 
that  server)  and  load  balancing  (i  e  ,  techniques  improving 
performance  and  scalability  not  observed  in  FF  domains). 

\on-CD\  domains  arc  valid,  benign  domains  that  don  7 
use  a  CDN  for  delivery  of  their  content.  Typically,  non-CDN 
domains  use  a  few  stable  content  servers  and  a  modest  num¬ 
ber  of  NScs,  with  the  same  A  and  NA  rec  IPs  appearing  in 
the  query  results  regardless  of  the  queried  DNS  serv  er's  ge¬ 
ographic  location. 

MAL  domains  are  domains  that  aren’t  fluxv  enough  to 
be  considered  FF  domains,  nor  benign  enough  to  be  con¬ 
sidered  non-CDN  domains.  While  not  necessarily  malicious 
domains,  their  DNS  behavior  demonstrates  potentially  sus- 
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Figure  I :  Global  I P-usage  (in  DNS  query'  results)  for  some  examples  of  the  domain  types 


picious  behavior  often  attributed  with  malicious  domains. 
They  tend  to  recruit  more  IPs  than  a  non-CDN,  but  not  nearly 
as  many  as  a  FF  domain  For  example,  during  a  monitoring 
period  of  a  few  months,  a  FF  domain  is  likely  to  advertise 
thousands  of  different  IPs  with  DNS;  even  a  fairly  slow  FF 
domain  will  advertise  in  the  hundreds.  A  MAL  domain,  on 
the  other  hand,  will  advertise  perhaps  a  total  of  20-30  IPs — 
roughly  one  or  two  IPs  every  few  days.  This  is  different  from 
a  non-CDN.  While  a  non-CDN  may  have  20-30  IPs,  they  arc 
all  seen  essentially  at  once  and  are  stable  for  the  duration  of 
the  monitored  period  MAL  domains  will  tend  to  slowly 
add  more  IPs  because  they  will  slowly  lose  some  as  their 
malicious  activities  are  detected  and  their  IPs  are  bloeked 
The  IPs  used  by  MAL  domains  may  consist  of  bots  or  valid 
servers  being  used  for  malieious  means.  Additionally,  be¬ 
nign  websites  hosted  on  home  computers  with  dynamic  IP 
addresses  could  be  considered  MAL  domains  by  our  defini¬ 
tion.  However,  we  consider  this  acceptable  since  most  valid 
websites  arc  not  hosted  on  home  computers,  causing  those 
that  are  to  be  inherently  suspect 

4.  GLOBAL  IP-USAGE  PATTERNS 

4.1  Overview 

In  this  section,  wc  explore  the  DNS  IP-usagc  patterns  of 
the  previously-described  domain  types,  identifying  interest¬ 
ing  and  differentiating  features  among  them.  We  accom¬ 
plish  this  by  analyzing  numerous  domains’  DNS-qucry  re¬ 
sults  from  vantage  points  dispersed  around  the  world.  This 
provides  us  with  a  unique,  global  perspective  of  how  the  dif¬ 
ferent  types  of  domains  advertise  their  IP  addresses  to  DNS 
servers.  First,  wc  will  describe  how  we  set  up  a  globally- 
distributed  DNS  monitoring  system  and  then  discuss  the  var¬ 
ious  features  we  have  identified  that  could  be  useful  in  the 
classif  ication  of  the  different  domain  types. 

4.2  System  Architecture 

Wc  created  a  distributed  DNS-query  engine  called  DIG¬ 
GER,  deployed  on  240  geographically  disparate  nodes  in  the 
Planetl  ab  testbed  [16].  The  nodes  were  chosen  based  on  the 
location  of  the  DNS  servers  they  queried,  such  that  DIGGER 
would  issue  queries  to  DNS  servers  in  different  geographic 
locations  around  the  world  Fig.  2  shows  the  distribution  of 
DIGGER  nodes,  which  is  reflective  of  the  overall  distribu¬ 
tion  of  av  ailable  PlanetLab  nodes. 

On  each  node,  for  malicious  and  benign  domains,  DIG¬ 
GER  performs  DNS-query  digs  on  their  A  ree,  NS  rec,  NA 
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Figure  2:  Global  distribution  of  DIGGER  nodes  by  continent 

rec  and  the  reverse  DNS  lookup  for  the  A  and  NA  rec  IPs 
Based  on  a  domain’s  most  recently  returned  DNS-query  re¬ 
sults.  DIGGER  classifies  the  domain  as  either  active  or  of¬ 
fline.  DIGGER  continues  to  dig  active  domains  periodical!} 
based  on  their  observed  TTL,  ensuring  fresh  DNS-query  re¬ 
sults.  Domains  determined  to  be  offline  are  intermittently 
dug,  so  that  DIGGER  can  discover  if  they  come  back  online 
Every  24  hours,  DIGGER  compresses  the  raw  DNS-qucry 
data  and  uploads  the  results  to  our  analysis  server  This  way 
wc  aggregate  the  global  DNS-query  results  for  over  106,000 
different  domains  from  240  nodes  around  the  globe  The  set 
of  domains  monitored  by  DIGGE*R  is  compiled  from  mul¬ 
tiple  sources,  including  online  repositories  of  phishing  [3] 
and  malware  [I  ]  websites.  In  addition,  wc  extract  domains 
from  URL  links  embedded  in  spam  emails  found  in  our  per¬ 
sonal  mail  boxes,  a  spam  relay  trap,  and  reeent  additions 
to  online  repositories  [10]  during  DIGGER’S  active  period. 
While  DIGGER  is  active,  wc  continue  to  gather  additionally 
suspicious  domains,  adding  them  to  DIGGER’S  monitoring 
set.  DIGGFR  has  been  deployed  and  gathering  global  DNS- 
usage  patterns  for  a  little  over  3.5  months.  Based  on  the 
analysis  of  this  data,  w  e  have  identified  several  differentiat¬ 
ing  features  between  malicious  FF  botnet  and  valid  domains, 
as  described  in  the  following  subsections. 

4.3  Overlap  betw  een  IPs  of  A  and  N  A  Records 

While  analyzing  our  data,  it  quickly  became  apparent  that 
FF  domains  tend  to  exhibit  some  IP  overlap.  Wc  were  seeing 
IPs  advertised  for  a  domain’s  A  rec  reappearing  in  the  same 
domain’s  NA  rec  We  discovered  that  the  malicious  domains 
were  not  only  reusing  their  available  IP  pool  for  both  A  and 
NA  rccs,  but  were  also  returning  IPs  from  the  same  IP  pool 
regardless  of  which  NS  was  queried,  resulting  in  different 
NScs  with  identical  IPs. 

Table  2  shows  the  total  number  of  A  rec,  NA  rcc,  and 
overlap  IPs  (i.c.,  IPs  appearing  in  both  the  A  and  NA  rcc)  for 
some  representative  domains  from  each  domain  type  This 


4 


Domain  Type  Domain 
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Figure  5:  Global  IP  usage  for  example  non-CDN  domain 


Tabic  2  Total  A,  NA,  c£  overlap  IPs  for  diff  domain  types 
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Figure  3:  Global  IP  usage  for  example  FFx2  domain 

overlap  phenomenon  was  much  more  prevalent  in  FFx2  do¬ 
mains  than  either  type  of  FFx  I ;  we  never  observed  it  in  valid 
domains.  The  FFx  I  domains  almost  entirely  use  valid  IPs 
for  one  record  type  and  the  IPs  of  compromised  computers 
for  the  other.  While  the  representative  MAL  domains  have  a 
small  number  of  total  unique  TPs  (like  a  non-CDN  domain), 
their  IP  overlap  is  exceptionally  high,  with  almost  all  of  their 
A  rce  IPs  also  used  for  their  NA  rees,  thus  setting  them 
apart  from  valid  domains.  The  IP  overlap  we  empirically 
observed  demonstrates  that  valid  domains  use  separate  ma¬ 
chines  for  their  content  and  name  servers  most  likely  for 
redundancy  and  fault-tolerance  purposes,  preventing  a  single 
point  of  failure.  FF  and  MAL  domains,  on  the  other  hand, 
attempt  to  make  the  most  of  their  limited  resources,  reusing 
IPs  for  both  the  A  and  NA  records.  Clearly,  the  amount  of 
observed  IP  overlap  can  prove  a  useful  feature  for  differenti¬ 
ating  between  valid  and  malicious  domains,  especially  FFx2 
and  MAL  domains 
4.4  IP  Recruiting 

Due  to  their  different  resources  and  management  tech¬ 
niques,  one  would  expect  FF,  CDN,  and  non-CDN  domains 
to  demonstrate  distinct  strategies  when  advertising  IPs  to 
DNS  servers.  To  conrtrm/refutc  this  expectation,  we  have 
analyzed  the  advertisement  strategies  for  the  various  domain 
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types.  For  a  given  domain,  wc  assumed  a  global  vantage 
point  across  all  DIGGER  nodes  and  assigned  a  unique  IP  in¬ 
dex  (in  ascending  order)  to  each  newly- seen  IP  in  the  DNS 
query  results.  This  IP  index  is  plotted  against  time  for  exam¬ 
ple  FFx2,  CDN,  non-CDN,  and  MAL  domains  in  Figs.  3-6, 
with  the  y-axis  representing  the  unique  IP  index  and  the  x 
axis  representing  the  time  in  seconds  since  DIGGER  was 
deployed.  The  example  domains  were  added  to  DIGGER 
about  I  month  after  its  deployment,  resulting  in  the  plots’ 
initial  lack  of  data  The  points  in  the  graphs  represent  w  hen 
an  IP  was  returned  in  a  DNS  query  on  a  global  scale  (i.e  , 
across  all  nodes  monitored  by  DIGGER).  Thus,  the  slope 
of  each  curve  demonstrates  the  rate,  or  speed,  w  ith  which  a 
domain  seems  to  globally  “recruit”  more  unique  IPs. 

It  should  be  noted  that,  by  definition,  FFxI„Arccand  FFxl  NArcc 
domains  are  essentially  specific  subsets  of  FFx2  domains. 

They  behave  like  a  FF  domain  in  one  record  type  and  like  a 
non-CDN  in  the  other.  Thus,  their  plots  arc  not  included  as 
they  arc  mostly  redundant 

MAL:  tsqriny.JukLrfujicf.cn  (A  r*c] 
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Figure  6:  Global  IP  usage  for  example  AL4L  domain 
Recruitment  Speed:  refers  to  the  speed  (or  rate)  at  which 
one  observes  new,  unique  IPs  for  a  given  domain  when  mon 
itoring  that  domain’s  DNS  queries  over  time. 

Fig.  3  shows  how  a  FFx2  domain  slowly  and  nearly  eon 
tinuously  accrues  unique  IPs  over  its  entire  online  lifetime, 
with  short,  intermittent  periods  of  stability.  These  results 
indicated  that  FF  domains — consisting  primarily  of  compro¬ 
mised  homc/office  computers  that  may  go  offline  arbitrarily 
must  continue  to  recruit  new  IPs  to  help  ensure  reliable  de¬ 
livery  of  their  nefarious  eontent.  In  addition,  the  bots  used 
by  FF  domains  often  obtain  dynamic  IP  addresses  from  their 
Internet  Service  Provider  (ISP)  via  DHCP  (Dynamic  Host 
Configuration  Protocol).  Consequently,  a  bot  may  be  as¬ 
signed  different  IPs  over  time,  causing  our  DIGGER  nodes 
to  observe  the  apparent  recruitment  of  new  IPs;  this  effect  is 
called  DHCP  churn ,  and  it  is  not  present  for  valid  domains 
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Figure  4:  Global  IP  usage  for  example  CDN  domain 
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using  stable  servers  with  static  IPs. 

Meanwhile,  when  viewed  globally,  wc  have  discovered 
that  CDN  domains  (Fig.  4)  achieve  a  much  faster  recruit¬ 
ment  speed,  indicating  that  they  advertise  IPs  from  a  large 
pool  of  stable  IP  addresses,  which  they  rotate  quickly  and 
efficiently  for  performance  purposes,  such  as  load  balanc¬ 
ing.  Our  data  also  reveals  that  CDNs  advertise  their  IPs  in 
a  geographical  ly-conscious  manner.  For  a  given  CDN  do¬ 
main,  a  DNS  query  in  Asia  will  often  result  in  a  different 
set  of  IPs  than  would  the  same  query  originating  in  Europe. 
This  is  because  the  CDN  would  mostly  advertise  (from  its  to¬ 
tal  pool  of  IPs)  IPs  located  in  Asia  to  Asian  DNS  servers  and 
IPs  located  in  Europe  to  European  DNS  servers.  As  a  result, 
DIGGER’S  global  perspective  observes  most  of  the  CDN's 
IPs  in  a  short  period  of  time.  In  contrast,  FF  domains  appear 
to  be  at  the  w  him  of  the  currently  available  and  online  bots, 
preventing  the  level  of  control  necessary  for  geographic  IP 
management.  Consequently,  they  tend  to  advertise  the  same 
pool  of  IPs  irrespective  of  the  DNS  servers'  geographic  lo¬ 
cation  Thus,  while  they  may  change  their  advertised  IPs  as 
quickly  as  a  CDN,  they  do  so  on  a  global  scale  (i.c.,  nearly 
the  same  IPs  arc  seen  regardless  of  query  location),  whereas 
a  CDN  is  more  localized  (i  e.,  IPs  returned  are  dependent 
on  the  queried  DNS  server’s  location).  Hence,  for  FF  do¬ 
mains,  DIGGER’S  global  perspective  doesn’t  allow  it  to  ob 
serve  many  more  IPs  than  at  any  given  local  vantage  point, 
resulting  in  the  comparatively  slower  IP  recruitment  rate. 

From  our  analysis,  wc  have  found  that  non-CDN  domains 
(Fig.  5)  hardly  recruit  any  additional  IPs  over  time.  Rather, 
their  IP  pools  consists  of  a  small  number  of  stable  content 
servers  that  arc  almost  simultaneously  advertised  to  DNS 
servers  around  the  world. 

Looking  at  Fig.  6,  wc  can  sec  that  tsqfsnyjukutuxef.cn 
demonstrates  the  slow  and  somewhat  steady  recruitment  of 
IPs  common  to  MAE  domains.  This  behavior  is  likely  the  re¬ 
sult  of  the  MAI  domains'  malicious  activities  being  detected 
and  their  IPs  blocked,  requiring  them  to  register  fresh  IPs 
with  DNS  in  order  to  maintain  content  availability.  Closer 
examination  reveals  that,  unlike  FF  domains  which  recruit 
hundreds  to  thousands  of  IPs,  MAL  domains  recruit  only 
tens  of  IPs  over  more  than  3  5  months.  This  is  a  drastic 
difference,  and  it  should  prove  beneficial  in  distinguishing 
MAI  domains  from  non-CDN  and  FF  domains. 

Recruitment  Period:  represents  the  amount  of  time  dur¬ 
ing  which  new  IPs  arc  seen  for  a  given  domain  when  mon¬ 
itoring  that  domain’s  DNS  queries  over  time.  Our  data  in¬ 
dicates  that  non-CDN  domains  (Fig.  5)  use  a  small  pool  of 
very  stable  IPs  with  almost  no  recruitment  period:  all  the  IPs 
used  arc  advertised  initially  and  used  throughout  the  lifetime 
of  the  domain.  On  the  other  hand,  wc  have  found  that  CDN 
domains  utilize  much  larger  IP  pools,  from  which  IPs  are 
advertised  based  on  geographic  location  and  load  balancing. 
When  viewed  from  a  global  perspective,  the  fast  recruitment 
speed  of  CDN  domains  causes  DIGGER  to  quickly  observe 
most  of  their  available  IPs,  resulting  in  a  short  recruitment 


period  at  the  onset  of  monitoring  follow  ed  by  a  longer,  stable 
period  consisting  mainly  of  previously-seen  IPs.  As  demon¬ 
strated  in  Fig.  4  wc  can  sec  that  the  CDN's  recruitment  pe¬ 
riod  is  smaller  than  its  total  online  period;  after  its  initial 
recruitment  period,  the  CDN  domain  stabilizes  and  adver 
tises  a  much  smaller  set  of  IPs  before  a  quick  advertisement 
spike  followed  by  another  stable  period.  We  have  also  dis¬ 
covered,  as  shown  in  Fig.  3,  that  the  fluxy  records  for  FF 
domains  recruit  new  IPs  for  nearly  the  entire  duration  of  the 
domains’  online  period,  with  only  short,  intermittent  periods 
of  stability.  That  is,  nearly  the  entire  time  wc  observe  a  FF 
domain  to  be  online,  its  fluxy  records  are  recruiting  new  IPs. 
This  constant  IP  recruitment  is  a  result  of  DHCP  chum  and 
the  unreliable  nature  of  the  compromised  computers  serving 
as  bots  The  vary  ing  recruitment  periods  wc  have  discovered 
for  the  different  domain  types  should  prov  ide  a  useful  metric 
for  distinguishing  between  them 

4.5  Continental  Distribution  of  IPs 

Next,  wc  examine  how  the  various  domain  types  differ 
in  their  IP  distribution  (i.c.,  where  the  IPs  returned  in  DNS 
queries  arc  geographically  located).  We  examine  the  geo 
graphic  location  of  IPs  based  on  continent  rather  than  coun¬ 
try,  because  the  close  proximity  of  European  countries  made 
a  country-based  resolution  too  finely-grained.  When  view 
ing  the  IP  distribution  based  on  continent,  however,  distin 
guishing  trends  between  the  domain  types  became  more  ap¬ 
parent  In  analyzing  a  domain's  IP  distribution  wc  asked  the 
following  questions 

Ql:  What  percentage  of  IPs  returned  in  DNS  queries  are 
located  in  a  different  continent  than  the  queried  DNS  server'1 
We  restate  this,  for  succinctness,  as  the  percentage  of  IP \ 
from  the  wrong  continent. 

Q2:  From  the  perspective  of  each  continent  containing 
queried  DNS  servers,  what  percentage  of  IPs  returned  are 
located  in  each  continent?  Likewise,  for  succinctness,  wc 
restate  this  as  the  continental  IP  distribution 

The  answer  to  Ql  can  be  seen  in  Fig.  7  for  some  represen 
tative  domains.  For  each  domain,  we  plotted  the  percentage 
of  A  and  NA  rec  IPs  from  the  wrong  continent.  From  Fig.  7, 
it  is  evident  that  the  CDN  domain  has  a  considerably  smaller 
proportion  of  IPs  from  the  wrong  continent  than  the  other 
domain  types.  For  both  the  CDN’s  A  and  NA  rec  IPs,  the 
percentage  from  the  wrong  continent  is  less  than  half  that  of 
the  next  lowest  domain. 

Insight  into  continental  IP  distribution  (Q2)  can  be  found 
in  Fig.  8  for  some  sample  domains.  For  brev  ity,  wc  have  not 
plotted  any  FFxl  domains,  sinec  their  results  arc  a  subset 
of  the  FFx2  domain  type,  likewise,  we  have  omitted  plots 
for  a  MAL  domain  (since  their  distribution  is  functionally 
similar  to  non-CDN  domains)  and  for  the  NA  rccs'  distri¬ 
bution  (since  the  results  arc  similar  to  those  for  the  A  rccs). 
In  Fig.  8,  the  bars  represent  the  continental  IP  distribution 
from  dilferent  perspectives.  In  each  domain's  plot,  the  first 
bar  represents  the  continental  IP  distribution  from  a  global 
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perspective,  while  the  other  bars  are  from  the  perspective  of 
the  different  continents  where  wc  deployed  DIGGER  nodes. 
For  example,  the  bar  labeled  “Asia”  under  old-and~girl.com 
(Fig  8)  indicates  the  percentage  of  A  rec  IPs  located  in  eaeh 
continent  base  on  queries  to  Asian  DNS  servers. 

It  is  interesting  to  note  in  Fig.  8  that  the  continental  IP 
distribution  for  both  FFx2  and  non  CDN  domains  is  fairly 
consistent  across  the  different  continents,  hardly  deviating 
from  the  global  distribution.  For  CDN  domains,  on  the  other 
hand,  the  distribution  varies  greatly.  These  results  elearly 
reveal  the  location-aware  DNS  advertisement  employed  by 
CDNs.  Their  DNS  query  results  often  contain  a  majority 
of  IPs  located  near  the  DNS  server  and  the  issued  query, 
providing  fast,  reliable  services  and  quicker  content  delivery 
to  end  users  by  reducing  the  data's  travel  distance.  Conse¬ 
quently,  CDNs  demonstrate  a  smaller  percentage  of  IPs  from 
the  wrong  continent  and  a  larger  variance  in  continental  IP 
distribution  than  other  domain  types. 

From  our  data,  we  found  that  MAL  and  non-CDN  do¬ 
mains  operate  in  a  similar  manner  With  a  smaller  set  of 
stable  servers  (both  content  and  name)  than  CDN  and  FF 
domains,  they  don't  require  complicated  load  balancing  or 
location- aware  DNS  advertisement  Instead,  we  discovered 
that  they  adopt  a  form  of  naive  DNS  advertisement  and  in¬ 
discriminately  advertise  their  small  pool  of  server  IPs  around 
the  world  nearly  simultaneously  (Fig.  5).  This  causes  the 
continental  IP  distribution  at  each  continent  to  be  the  same 
as  the  global  distribution.  Consequently,  the  percentage  of 
IPs  from  the  wrong  continent  will  reflect  the  global  distri¬ 
bution  of  our  DIGGER  nodes,  depending  on  the  location  of 
the  non-CDN  domain's  servers.  Fig  8  shows  that  for  the 
non-CDN  domain  hostingprod.com ,  all  of  the  A  rec  IPs  are 
in  N  America.  Because  about  46%  of  our  nodes  arc  lo¬ 
cated  in  N.  America  (Fig.  2).  we  find  that  53.77%  of  host- 
ingprod. corn's  IPs  arc  from  the  wrong  continent  (Fig.  7),  ap 
proximatcly  (due  to  rounding)  the  same  percentage  as  nodes 
not  in  N.  America. 

Our  analysis  suggests  that  FF  domains  adopt  an  advertise¬ 
ment  strategy  dictated  by  the  unstable  nature  of  their  con¬ 
stituent  hots,  which  we  term  necessity-based  D NS  advertise¬ 
ment.  Since  hots  can  go  offline  at  any  time,  FF  domains 
must  rely  on  whichever  bots  arc  currently  available,  regard¬ 
less  of  geographic  location.  While  FF  domains  don't  concur¬ 
rently  advertise  their  entire  IP  pool  globally  (as  non-CDNs 
do),  they  eventually  advertise  most  of  their  IPs  globally  FF 
domains  appear  to  advertise  available  IPs  to  DNS  servers 
around  the  globe  as  necessity  dictates,  with  little  or  no  re¬ 
gard  to  location,  resulting  in  a  large  percentage  of  IPs  from 
the  wrong  continent  and  a  fairly  consistent  continental  IP 
distribution  across  continents. 

Our  findings  indicate  that  the  percentage  of  IPs  from  the 
wrong  continent  and  the  variance  of  the  continental  IP  dis¬ 
tribution  eould  servo  as  features  for  distinguishing  CDN  do¬ 
mains  from  the  other  domain  types.  This  can  greatly  sim¬ 
plify  the  detection  of  FF  domains  by  helping  identify  them 


Figure  7;  Percentage  of  IPs  from  the  wrong  continent 
from  CDNs,  which  arc  often  very  similar  in  other  respects 

4.6  Number  of  Unique  IP  Addresses  per  Node 

Another  interesting  feature  is  the  number  of  unique  IPs 
seen  across  the  DIGGER  nodes  over  time.  Fig.  9  shows  the 
CDFs  for  the  numbers  of  unique  A  and  NA  rec  IPs  observed 
by  our  240  DIGGER  nodes  during  the  ^3.5  month  monitor¬ 
ing  period.  Again,  MAL  domains  have  been  omitted  in  the 
plots  due  to  their  similarity  to  non-CDN  domains.  Our  enr 
pirical  data  reveals  that  non-CDN  and  FFxl  _NArcc  domains 
(whose  A  rccs  behave  like  a  non-CDN)  use  a  small  set  of 
stable  content  servers.  For  example,  in  Fig.  9  (a),  neither  of 
them  contains  more  than  18  unique  A  rec  IPs  per  node.  CDN 
domains  arc  found  to  exhibit  a  large  number  of  unique  A  rec 
IPs  on  some  nodes,  though  the  number  of  nodes  is  consid¬ 
erably  fewer  than  observed  for  FF  domains.  For  example, 
for  the  CDN  in  Fig  9qa),  ~84%  of  the  DIGGER  nodes  oh 
served  less  than  22  unique  A  rec  IPs  and  no  node  ohserved 
more  than  200.  On  the  other  hand,  for  the  FFxl_Arcc  and 
FFx2  domains,  we  observed  a  greater  number  of  unique  A 
rec  IPs  on  a  larger  percentage  of  nodes  For  the  FFx  1  _Arec 
domain  in  Fig.  9  (a),  %45%  of  the  nodes  detected  over  100 
unique  A  rec  IPs  more  than  35%  detected  over  200,  and  a 
few  observed  over  700.  The  numbers  observed  for  the  FFx2 
domain  are  even  higher,  w  ith  over  80%  of  the  nodes  observ¬ 
ing  more  than  100,  ^43%  more  than  500.  and  several  with 
more  than  2,500  Clearly,  the  FFxl  _Arcc  and  FFx2  domains 
possess  a  much  higher  average  number  of  unique  A  rec  1  Ps 
per  node—  a  direct  consequence  of  the  bots’  unreliable  con 
ncctivity  and,  to  a  lesser  extent,  DHCP  churn. 

While  the  number  of  unique  A  rec  IPs  per  node  appears 
a  promising  distinguishing  feature,  our  data  implies  that  this 
is  not  the  case  for  the  average  number  of  unique  NA  rec  IPs. 
For  example,  from  Fig.  9-(b)  it  is  apparent  that  CDN  and 
FFx2  domains  possess  many  more  unique  NA  ree  IPs  per 
node  than  the  other  domain  types.  Although  the  CDN  do¬ 
main  appears  to  utilize  more  unique  NA  rec  IPs  per  node  on 
average,  the  FFx2  domain  demonstrates  a  greater  number  of 
unique  IPs  at  a  single  node:  999  IPs  to  the  CDN  domain's 
727.  It  seems  that,  over  time,  CDNs  can  advertise  numerous 
NScs  with  DNS,  resulting  in  an  excessive  number  of  unique 
NA  rec  IPs  per  node.  This  behavior  might  arise  from  the 
CDN  trying  to  ensure  the  availability  of  its  NSes,  afford- 
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Figure  8‘  Percentage  of  total  A  ree  IPs  seen  from  each  continent  by  DIGGER  nodes  globally  and  in  each  continent 


(a)  (b) 

Figure  9:  CDF:  U  of  unique  A  and  NA  rec  IPs  per  node 

ing  it  better  eontrol  when  performing  load  balancing  In  any 
case,  we  found  the  behavior  of  the  FF  and  CDN  domains  to 
be  too  similar,  causing  the  number  of  unique  NA  ree  IPs  to 
be  an  indistinctive  feature. 

4.7  Total  Number  of  Unique  IPs 

Based  on  our  data,  we  learned  that  non-CDN  and  MAL 
domains  advertise  only  a  few  stable  content  and  name  servers 
with  DNS.  In  the  case  of  non-CDN  domains,  nearly  all  lhc 
A  and  NA  ree  IPs  arc  advertised  ubiquitously  around  the 
globe.  For  MAL  domains,  a  smaller  number  of  IPs  are  used 
at  any  given  time,  however,  over  time,  as  the  MAL  domain 
becomes  detected  and  its  IPs  blocked,  the  number  of  unique 
IPs  will  slowly  increase.  In  either  ease,  the  total  number  of 
unique  A  and  NA  ree  IPs  for  MAL  and  non-CDN  domains  is 
meager  when  compared  to  CDN  and  FF  domains  (Table  2), 
making  it  a  useful  distinguishing  feature. 

4.8  Reverse  DNS  Lookup  and  TTL 

Because  an  IP's  reverse  DNS  name  is  set  by  its  ISP  and 
not  the  owner  of  the  domain,  it  cannot  be  faked  by  a  bot- 
master.  This  makes  it  a  fairly  useful  metric  for  identify¬ 
ing  bots,  whieh  would  contain  reverse  DNS  names  typical 
to  home  computers  (i.e.,  containing  words  like  comcast,  dy 
namie,  dial-up,  etc.).  Unfortunately,  the  reverse  DNS  lookup 
is  highly  unreliable,  often  not  returning  a  result  Addition 
ally,  w'e  don’t  have  a  complete  list  of  suspicious  words,  and 
occasionally,  the  presence  of  such  words  may  not  be  indica¬ 
tive  of  a  bot.  Therefore,  we  have  decided  not  to  incorporate 
the  reverse  DNS  name  for  automatic  domain  classification, 
hoping  to  gam  better  insight  into  more  reliable  features.  In¬ 


stead.  when  present,  we  use  it  to  help  reinforce  or  confirm 
our  manual  identification  of  the  different  domain  types. 

The  A  and  NA  rccs’  TTL  values  also  appear  highly  use¬ 
ful  for  differentiating  between  the  domain  types  However, 
unlike  many  of  the  other  features  we  have  previously  ex¬ 
plored,  the  TTL  value  is  not  an  uncontrollable  consequence 
of  FF  domains,  it  is  set  by  the  owner  of  the  domain,  afford 
ing  botmasters  a  convenient  mechanism  for  circumventing 
TTL-dcpcndent  detection  metrics  In  addition,  it  has  been 
shown  in  [13]  that  the  TTL  distribution  of  FF  domains  and 
many  popular  websites  (especially  CDN  domains)  are  simi 
lar.  Consequently,  we  have  decided  not  to  use  the  TTL,  as  a 
classification  feature.  It  should  be  noted  that  other  features, 
like  the  recruitment  speed  and  period,  cannot  be  as  easily 
manipulated  by  the  botmaster,  since  the  unstable  bot  IPs  ne¬ 
cessitate  constant  recruitment 

4.9  Other  Features 

For  the  various  domain  types,  we  also  examined  the  aver¬ 
age  number  of  nodes  per  IP  and  the  average  IP  online  time. 
While  these  results  proved  interesting  and  potentially  useful 
as  distinguishing  features,  we  found  them  less  effective  than 
the  other  features  when  designing  our  classifier  (Section  5) 
Therefore,  due  to  space  constraints,  we  have  omitted  our  re¬ 
sults  concerning  these  features  and  refer  the  interested  reader 
to  our  technical  report  for  their  discussion. 

5.  DETECTION  MET  HODOLOGY 

5.1  Overview 

Our  observations  in  Section  4  indicate  that  the  different 
domain  types  could  be  identified  based  on  behavioral  fea¬ 
tures  of  their  global  DNS  activity  To  demonstrate  this,  we 
built  a  proof-of-conccpt  classifier,  utilizing  a  multi-leveled 
linear  SVM  (Support  Vector  Machine).  The  rest  of  this  sec¬ 
tion  describes  its  design  and  implementation,  including  how 
we  quantified  the  behavioral  features,  chose  whieh  features 
to  apply  at  each  stage  (or  level),  determined  the  order  of  the 
stages,  and  finally,  how  the  SVMs  were  trained, 

5.2  Classification  Features 

Table  3  shows  the  features  we  considered  using  in  the 
classifier  and  how  they  are  likely  to  group  the  domain  tv  pcs. 
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Each  feature  has  been  given  a  number  to  simplify  its  repre¬ 
sentation  throughout  the  paper.  With  the  exception  of  fea¬ 
ture  F2,  each  feature  can  be  applied  to  a  domain’s  A  or  NA 
rec,  and  while  not  displayed  in  Table  3,  the  features  can  also 
be  applied  to  the  combined  IP  pool  of  the  A  and  NA  rccs, 
represented  as  (A  +  NA).  Lastly,  the  column  labeled  “Do¬ 
main  Type  Classification  Groups-'  in  Tahle  3  shows  how  each 
feature  when  applied  to  the  A  or  NA  rec  will  likely  group 
the  different  domain  types,  represented  by  square  brackets. 
Table  3  docs  not  express  hard-and-fast  rules  for  how  features 
classify  the  domain  types.  Rather,  it  show  s  likely  groupings: 
domain  types  tending  to  produce  similar  results  with  respect 
to  a  given  feature  and  record  type.  Thus,  Table  3  is  a  help¬ 
ful  visual  tool  for  determining  the  application  of  features  at 
different  SVM  levels 


Clarification  feature 

DNS 

Record 

Domain  Type 
ClassificaUon  Groups 

FI.  A vg  a  of  unique  IPs  per  Node 

A 

•ICON  ->orCON.,MAl  FFxl  NArec  ] 

•  [ffx2„  FFxl  Arec  . 

NA 

•  (CON..  •  [FFxl  NArec, j 

•  (non  CON  ,  MA.  ,  FF*l Arec 

F2.  A  &  NA  rec  overlap 

A  A  NA 

•  (CON;,  nor  CON.| 

•  [MAl  "Fx2.u  FFxl_Ar*c  FFxl^NArec-| 

F3.  S  IPs  from  wrong  continent 

A 

NA 

•  (CON 

•  [non-CON.,  MAI..,  FFx24. 

FFxl  Arec*  FFxl  NArec,] 

FA.  Continental  IP  distribution  s 
average  cosne  similarity 

A 

NA 

FS.  P  recruiting  s oe rd 

A 

•  (CDN  •  Jnon  CDN FF»l_NArec 
•[MAL,;  •  (FFx2,.FFxl_Arec 

NA 

•  (CON  ;  •  (non  CDN,,  F-xl_Arec  ) 

•  (MAL.j  •[FF«24,  FFxl  NA  ec, 

F6.  IP  recruiting  penoo 

A 

•  [CON  •  •  (non  CON,  FFxl  NArec 

•  [MAL  ]  •  [FF<2i.  Ff  xl  Arec 

NA 

•  (CDN  |  •  (non  CON,,  FFxl  Arec. ( 

•  (MAL  •  [FF*2  FFxl  NA  cC 

F7.  Total  unique  |F*S 

A 

NA 

•  [CON  ,  FFxZ  ,  Ffxi_Arec.  J 

•  (non TON  .  MAL,.  Fcxi_NArec 

•  [CON  «-Fx2  ,  FFxl  NArec,) 

•  (non  CON.,  MAL,.  FFx:_Arec«j 

The  number  by  each  demer  rype  represents  the  le/el  >t n  Classified  by  our  iV.V. 
When  selecting  features  for  SVM-  x  domains  wrt/i  a  number  <  x  con  be  >qno  ed 
smee  tney  houe  olready  been  classified  and  removed  from  the  unknown  set 


Table  3:  Features  to  classify  domain  types  into  diff  groups 
5. 2. 1  Feature  Quantification 

All  of  the  features,  except  12,  were  quantified  using  the 
IPs  of  the  three  different  record  types — A,  NA  and  (A  +  NA) 
recs  to  produce  3  distinct  values.  Which  of  these  values 
is  used  at  each  stage  of  the  classifier  is  discussed  in  Sec¬ 
tion  5.3.2.  Each  feature  is  calculated  for  each  domain  moni¬ 
tored  by  DIGGER  over  the  total  =^3.5  month  duration 

FI:  Let  Pi  =  nurnher  of  unique  IPs  on  node  /,  and  let 
N  =  number  of  nodes  (of  the  240  total)  where  the  number  of 
unique  IPs  >  1  Then,  FI  is  computed  as: 

yv  p 

Fl  =  ^p  (I) 

Jy 

F2:  represents  the  percentage  of  unique  IPs  that  overlap 


between  the  A  and  NA  rccs.  Thus,  if  all  the  IPs  from  one 
record  type  arc  also  used  for  the  other  record  type,  there  w  ill 
be  a  100%  IP  overlap  For  a  given  domain  across  all  nodes, 
let  Pa  be  the  set  of  unique  A  rec  IPs  and  P\a  be  the  set  of 
unique  NA  rec  IPs.  Then,  F2  is  calculated  as: 


F2  = 


(2) 


F3:  Using  an  online  database  [2]  and  whois  lookup,  we 
were  able  to  determine  the  country  of  origin  for  most  IPs 
observed  by  DIGGER  and  the  continent  the  IP  was  located 
on:  N.  America,  S.  America,  Europe,  Asia,  Africa,  Oceania, 
Antarctica,  and — very  rarely — unknown.  Let  W,  =  number 
of  unique  IPs  on  node  i  that  are  located  in  a  different  (i.e  , 
wrong)  continent  than  node  /.  Let  P )  and  /V  be  defined  as  for 
F 1 .  Then,  F3  is  computed  as: 


F3  = 


i;v  i 


HI 

p, 


(3) 


F4:  Let  the  continents  N.  America,  S  Amenca,  Europe, 
Asia,  Africa,  Oceania,  Antarctic  and  “unknown"  be  repre 
sented  by  the  numbers  1-8,  respectively.  Then,  tu  =  num¬ 
ber  of  nodes  on  continent  A,  for  I  <  k  <  4  (continents  w  ith 
DIGGER  nodes).  For  node  j  on  continent  A\  let  dj  be  a  vec¬ 
tor  representing  the  number  of  unique  IPs  seen  from  each 
continent.  Thus,  a[  is  the  number  of  unique  IPs  from  con 
tinent  k  that  were  seen  on  node  j.  Then,  for  each  continent 
k  with  DIGGER  nodes,  where  I  <  k  <  4,  we  calculate  Ak 
as  shown  in  Eq.  (4).  We  calculate  the  cosine  similarity- 
shown  in  Eq  (5) — between  every  possible  pair  of  vectors 
Ak ,  for  1  <  k  <  4,  and  then  take  the  average,  producing  the 
IP  continental  distribution's  average  cosine  similarity  (F4) 
The  closer  this  value  is  to  1 ,  the  more  similar  the  continental 
IP  distributions  appear  on  each  continent,  and  the  less  likely 
the  domain  is  a  CDN  domain 


-4*  =  £  ^  (4)  Similarity (X.  f")  =  (5) 

F5/F6;  First,  we  calculate  a  domain's  online  time,  de 
noted  as  Ta.  Analyzing  all  available  DNS  query  data  from 
all  nodes,  w  e  consider  an  online  point  to  be  a  point  in  time 
where  we  have  observed  IP  addresses  in  DNS  queries  on  the 
domain.  If  the  difference  in  time  between  two  consecutive 
online  points  is  less  than  a  threshold  of  several  hours,  it's 
added  to  T0  Next,  we  calculate  the  domain's  recruit  lime, 
denoted  as  Tr.  We  consider  a  recruit  point  to  be  a  point  in 
time  where  we  have  observed  a  new  IP  address  (i.e.,  one  that 
hasn’t  occurred  earlier  in  time).  If  the  difference  in  time  be¬ 
tween  two  consecutive  recruit  points  is  less  than  the  thresh 
old,  it's  added  to  T,.  Let  P  —  the  total  number  of  unique 
IPs  ohserved  glohally  for  a  domain  Then,  the  IP  recruiting 
speed  (F5)  and  period  (F6)  arc  calculated  as: 


F6-£.  (7) 
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In  those  instances  where  all  of  a  domain's  IPs  are  observed 
instantaneously,  resulting  in  a  Tr  =  0,  we  set  F5  to  I  This 
value  corresponds  to  a  rate  of  one  new  IP  every  second,  and 
it  was  great  enough  in  magnitude  from  all  other  observed 
values  to  serve  as  a  rough  approximation  lor  infinity. 

F7:  We  look  at  every  DNS  query  gathered  by  all  the  DIG¬ 
GER  nodes,  counting  the  number  of  unique  IPs  (F7).  It  rep¬ 
resents  the  total  unique  IPs  used  globally  by  a  domain. 

5.3  SVM  Classifier 

5. 3. 1  Rule-based  Filter 

Before  testing  our  SVM  classifiers,  we  applied  a  simple, 
rule  based  filter  to  remove  any  domains  that  were  highly  un¬ 
likely  to  be  CDN.  FF  or  MAE  domains.  The  filter  removed 
a  domain  from  the  test  set  only  if  all  of  the  following  four 
rules  apply:  ( I )  none  of  its  IPs  (in  both  A  and  NA  rccs)  have 
a  max  TTL  <  I  day,  (2)  its  A  and  NA  recs  contain  <  10 
IPs  over  the  entire  monitoring  period,  (3)  none  of  its  IPs  had 
reverse  DNS  lookups  containing  a  suspicious  word  (e  g.,  dy¬ 
namic,  dialup,  etc.)  and  (4)  none  of  its  IPs  had  reverse  DNS 
lookups  indicating  it  was  a  known  CDN  domain  (i.c.,  con¬ 
taining  words  like  akamai). 

Both  CDN  and  FF  domains  would  be  impractical  if  none 
of  the  IPs  had  TTL  values  <  I  day.  Similarly,  CDN  and  FF 
domains  should  aeerue  more  than  10  IPs  after  ^3.5  months 
of  monitoring,  as  should  any  MAE  domains  using  stable 
servers  and  acting  sufficiently  suspicious  (i.c..  their  IPs  are 
hccoming  blocked).  Therefore,  domains  satisfying  the  first 
two  conditions  are  extremely  unlikely  to  be  CDN,  FF  or 
MAI  domains.  As  an  additional  measure,  the  filter  also 
ensures  that  none  of  their  reverse  DNS  lookups  return  any 
suspicious  words  or  indicate  that  they  belong  to  a  CDN.  No 
tiec  that  any  domains  which  were  dead  (1  e.,  no  IPs)  for  the 
entire  monitoring  period  will  satisfy  all  4  conditions  and  be 
removed  from  the  test  set.  When  applied,  the  filter  removed 
100.889  unsuspicious  or  dead  domains  from  our  initial  set  of 
106,31 1  domains,  reducing  it  to  5,422.  Finally,  we  removed 
253  domains  with  insufficient  DNS  query  data  (250  domains 
were  momentarily  observed  by  single  nodes  and  3  domains 
were  monitored  by  less  than  25%  of  our  DIGGER  nodes), 
bringing  the  test  set  to  5,1 69  domains 

5.3.2  Multi-level  SVM 

Fig.  10  shows  the  design  of  our  multi-leveled  SVM  clas¬ 
sifier  and  the  results  of  our  training  and  test  sets.  Each  level 
of  the  SVM  classifies  a  domain  type  from  the  test  set,  pro¬ 
gressively  reducing  the  number  of  unknown  domains  and 
thus  simplifying  subsequent  classification.  Bach  o\al  in  the 
figure  represents  a  classified  domain  type,  while  each  rect¬ 
angle  represents  the  remaining  unknown.  The  values  for 
’Train”  show  how  many  examples  of  a  given  domain  type 
(or  group  of  domain  types)  were  used  when  training  that 
lev  el  of  the  classifier.  I  he  values  lor  “Test”  indicate  the 
number  of  domains  that  were  classified  (or  remained  to  be 
classified)  when  we  applied  each  tier  of  the  classifier  to  our 


test  set.  We  manually  identified  about  10  representative  do¬ 
mains  of  each  type  to  be  used  in  training,  as  show  in  Fig  1 0. 
More  difficult  to  detect  by  hand,  we  were  only  able  to  man¬ 
ually  identify  one  FFxl.NArcc  domain 

Table  4  shows  the  bias  and  feature  weights  for  each  level 
of  our  classifier.  Those  features  not  used  at  a  particular  level 
arc  shaded  black.  For  each  SVM,  the  Result  is  calculated  as 
the  bias  term  plus  the  product  of  each  feature  and  its  weight 
The  “ Result  >  0”  column  indicates  how  a  domain  with  a  pos¬ 
itive  Result  will  be  classified.  The  exception  is  FF\1  NArce 
domains,  which  are  classified  when  SVM-5\s  Result  is  nega¬ 
tive.  Additionally,  the  magnitude  of  Result  signifies  the  eon 
fidence  in  classification  choice. 

As  each  domain  type  is  classified,  it's  removed  from  the 
set  of  unknown  domains  before  applying  the  next  SVM  level 
Due  to  the  similarities  some  domain  types  share  between 
certain  features,  the  order  we  apply  the  classifiers  and  which 
features  we  use  at  each  level  becomes  important.  The  proper 
order  can  explott  the  strong  differentiating  features  between 
certain  domain  types.  We  will  now  explain  the  features  used 
at  each  level  of  our  SVM  classifier  and  justify  the  order  of 
classification. 

SVM-1:  From  Tabic  3,  we  sec  that  F3  and  F4  are  strong 
indicators  of  CDN  domains  due  to  their  DNS  strategy;  none 
of  the  other  domain  types  display  this  location-aware  behav 
ior.  Therefore,  we  can  remove  CDN  domains  from  the  un¬ 
known  set  first  with  high  accuracy.  Since  CDN  domains  can 
behave  similarly  to  FF  domains  in  other  respects,  removing 
them  first  will  improve  successive  classification.  I  or  these 
reasons,  SVM- 1  was  trained  on  10  CDN  domains  and  40 
other  domains  (i.c.,  non-CDN.  MAL,  and  FF),  using  F3  and 
F4  on  the  domains'  A  and  NA  rccs.  As  we  can  sec  from 
Table  4,  a  large  percentage  of  IPs  from  the  wrong  continent 
(F3)  or  similar  IP  distributions  on  each  continent  (F4)  will 
generate  a  negative  Result  We  ran  SVM- 1  on  our  test  set 
of  5.169  domains.  It  identified  a  total  of  17  CDN  domains, 
which  we  manually  verified  then  removed  from  the  test  set. 

SVM-2;  While  non-CDN  domains  advertise  all  their  IPs 
nearly  instantaneously,  both  MAL  and  FF  domains  will  need 
to  recruit  IPs  over  time  Additionally,  MAL  and  FF  do¬ 
mains  may  possess  IP  overlap;  this  should  never  be  the  case 
for  valid  non-CDN  domains.  Thus,  for  SVM-2,  we  use  F5. 
F6,  and  F2  on  the  comhincd  (A  +  NA)  recs,  accouming  for 
I  Fxl  domains  demonstrating  fluxy  behavior  in  only  a  single 
record  type.  We  trained  SVM-2  on  I  I  representative  non- 
CDN  domains  and  29  of  the  FF  and  MAL  domains.  When 
applied  to  the  remaining  5,152  unknown  domains,  it  classi¬ 
fied  279  as  non-CDN.  We  manually  analyzed  the  69  border 
eases  with  Results  closest  to  0  and  found  them  to  be  satis¬ 
factorily  classified:  these  results  will  be  discussed  further  in 
Section  5.4  I .  From  Tahle  4,  we  can  sec  that  F6  is  the  dom¬ 
inating  feature.  If  the  domain  demonstrates  am  significant 
recruitment  period,  it  is  unlikely  to  be  a  non-CDN  domain 
Had  CDN  domains  not  been  previously  classified  and  re¬ 
moved,  this  feature  would  have  been  less  useful 
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Figure  10:  SVM flowchart 


Tabic  4  Linear 

SVM-3:  After  removing  the  non-ODN  domains  identi¬ 
fied  by  SVM-2.  the  test  set  was  entirely  composed  of  mali¬ 
cious  domains  (i.e.,  FF  and  MAL).  Due  to  the  many  similar¬ 
ities  between  FFx  1  and  FFx2  domains,  it’s  logical  to  classify 
MAL  domains  next.  F7  is  the  most  obvious  distinguishing 
feature  between  MAL  and  FF  domains,  but  we  suspected 
that  F5  and  F6  might  also  prove  useful,  since  FF  domains 
should  recruit  more  LPs  over  a  greater  percentage  of  their 
online  tune.  SVM-3  applies  F5,  F6  and  F7  to  the  domains' 

(A  +  NA)  recs,  accounting  for  FFx  I  domains.  We  trained 
SVM-3  on  a  representative  set  of  10  MAL  domains  and  19 
FF  domains.  When  applied  to  the  test  set  of  4,873  malicious 
domains,  it  identified  4.694  MAL  domains  and  179  FF  do¬ 
mains.  Looking  at  SVM-3  in  Table  4,  we  see  that  the  domi¬ 
nant  distinguishing  feature  is  F7:  the  number  of  unique  IPs 
Because  of  their  faster  IP  recruitment  rate,  FF  domains  will 
quickly  outpace  MAL  domains,  resulting  in  a  much  larger 
number  of  unique  IPs. 

SVM-4;  After  three  stages  of  the  classifier,  only  FF  do¬ 
mains  remained  in  the  test  set.  By  definition,  the  only  thing 
distinguishing  FF  domains  is  which  record  type  demonstrates 
tluxiness.  A  combination  of  the  two  FFx  I  domain  types. 
FF\2  domains  are  the  next  candidate  for  classification.  From 
Table  3,  it  appears  that  applying  FI,  F2,  F5,  F6  and  F7 
to  the  indiv  idual  A  and  NA  recs  should  discern  FFx2  from 
FFxl  domains  For  FI,  F5,  F6  and  F7,  all  the  FF  domains 
will  demonstrate  ftuxy  behavior,  but  the  FF\2  domain  will 
demonstrate  twice  as  much  as  either  type  of  FFxl  domain 
Additionally,  the  IP  overlap  (F2)  experienced  by  FFx2  do¬ 
mains  should  be  considerably  larger.  We  trained  SVM-4  on  a 
representative  set  of  1 1  FFx2  domains  and  8  FFxl  domains. 

W  hile  F5  appears  less  significant,  F2.  F6.  and  F7  contribute 
nearly  equally  in  classification,  and  FI  is  a  strong  indica¬ 
tor  of  FFx2  domains  These  results  and  their  implications 
arc  covered  in  Section  5.4  3  Applying  SVM-4  to  the  179 
remaining  FF  domains  identified  38  FFx2  and  141  FF  x  1  do¬ 
mains,  which  we  manually  verified 

SVM-5:  The  final  level  of  the  classifier  is  responsible 
for  discriminating  between  FFxl^Arcc  and  FFxLNArcc  do 


S  VK1  equations 

mains.  With  the  exception  of  F2,  SVM-5  makes  use  of  the 
same  features  and  record  types  as  SVM-4  for  similar  rea¬ 
sons.  F2  is  ignored  at  this  stage  since  the  FFxl  domains 
should  experience  comparable,  modcst-to-no  IP  overlap.  If 
a  FFxl  domain  demonstrates  too  much  IP  overlap,  the  fluxy 
behavior  becomes  visible  in  both  record  types,  and  the  do¬ 
main  can  be  considered  FF.\2.  The  usefulness  of  the  other 
features  is  straightforward:  for  FFxl  Arcc  domains,  the  fea 
tures  will  appear  more  fluxy  in  the  A  rces.  and  the  oppo¬ 
site  holds  for  FFxl  _NArec  domains.  When  applying  SVM-5 
to  the  141  FFxl  domains,  we  were  surprised  to  find  53  of 
them  were  actually  classified  as  FI  xl.NArec  domains  Wre 
examined  the  results  by  hand  and  discovered  they  were  in¬ 
deed  correctly  identified  as  FFxl-NArec  domains.  We  will 
examine  these  results  and  possible  explanations  in  in  Sec¬ 
tion  5  4  4.  Table  4  shows  that  F5  and  F6  became  negligible 
for  SVM-5.  FI  holds  some  influence  in  classification,  but 
the  dominating  feature  is  clearly  F7,  since  the  fluxy  record 
type  naturally  accrues  more  IPs  with  time. 

5.4  Results 

5.4  I  False  Positives 

From  our  classifier  s  results  at  each  stage.  onlv  SVM-2 
was  found  to  experience  any  false  positives:  two  FFxl _Arc*c 
domains  were  incorrectly  identified  as  non-CDN  due  to  DNS 
domain  IP  parking  When  we  initially  analyzed  DIGGER'S 
data,  we  discovered  a  couple  of  nodes  that  reliably  partook 
in  IP  parking  using  the  same  set  of  IPs  Their  parking  behav¬ 
ior  is  easily  observed  in  Fig.  II  as  two  long,  constant  lines 
with  positive  Node  Index  values,  indicating  parking  in  the 
A  rec.  Appearing  as  consistent,  stable  IP  addresses,  these 
parked  IPs  cause  a  domain  to  seem  more  benign  than  it  actu¬ 
ally  is,  and  if  their  influence  dominates,  our  classifier  could 
consider  the  domain  to  be  non  CDN  We  removed  the  in 
fluencc  of  IP  parking  due  to  these  two  nodes  by  ignoring 
the  associated  parking  data  when  present.  However,  in  real 
lty,  these  wore  not  the  only  nodes  performing  IP  parking 
though  they  were  the  most  consistent.  Since  we  didn't  filter 
this  behavior  for  all  nodes,  it  affected  classification,  account- 


11 


tu*wfenform  voJkib*ofc.rt«  rrwxW-n* 


FF x2:  ehuytyl.cn  (NA  r«c) 


Figure  I  I ;  FF.xI.Arec  domains  with  IP  parking 


MAL:  room  e.mooo  com  MAL  room  •  mooo  com  (A  rec) 


FFx2:  ehuytyt.cn  (A  r*c) 


Twm  (•*€*]  x10« 


Figure  13:  Classified  FFx  2  domain 
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Figure  12:  Cautious  MAL  domain 
ing  For  SVM  2's  two  Fatsc  positives.  For  example,  consider 
the  similar  domains  in  Fig.  1 1 .  In  both  eases,  the  two  known 
nodes  were  ignored,  causing  the  domain  in  Fig  ll-(a)  to 
be  classified  correctly.  However,  though  initially  the  do¬ 
main  in  Fig.  1 1 -(b)  appears  fluxy,  the  parking  behavior  of 
a  large  majority  of  nodes  dominates  over  its  lifetime,  caus¬ 
ing  it  to  be  classified  as  non-CDN.  While  considered  a  false 
positive,  this  labeling  is  rather  subjective;  For  the  majority  of 
the  domain’s  lifetime  it  does  resemble  a  non-CDN  due  to  IF 
parking.  Since  our  classifier  is  temporally  naive,  using  all 
available  data  over  the  ^3.5  month  monitoring  period,  this 
miselassification  is  entirety  reasonable 

5.4.2  Cautious  MAL  domains 

While  manually  validating  $VM-3’s  results,  we  discov¬ 
ered  4  borderline  MAL  domains  exhibiting  atypical  IP  be¬ 
havior,  one  of  which  is  shown  in  Fig.  12  Recruiting  less  than 
50  A  rce  IPs  over  %  2. 5  months  (the  domain  was  parked  after¬ 
wards).  it  is  not  fluxy  enough  to  be  considered  a  FFx I  _Arec 
domain.  However,  its  uncannily  regular  tP  recruitment  dis¬ 
tinguishes  it  from  other  MAL  domains.  Further  analysis 
revealed  that  the  domains  advertise  only  a  single  A  ree  IP 
per  query,  with  a  max  ITL  of  one  minute.  Despite  this  fine 
level  of  control,  the  domains  only  replace  the  tP  about  once  a 
day,  adhering  to  a  meticulously  precise  schedule.  Addition¬ 
ally,  w'c  can  see  from  Fig.  12,  that  once  changed,  the  A  rce 
IPs  arc  not  reused.  Since  these  malicious  domains  are  not 
fluxy  enough  to  be  considered  FF,  they  arc  correctly  clas¬ 
sified  as  MAL  domains,  but  their  behavior  implies  a  man¬ 
agement  strategy  different  from  most  MAL  domains  They 
appear  to  be  a  type  of  cautious  MAL  domain,  regularly  and 
preemptively  replacing  their  A  ree  IPs  before  they  can  be  de¬ 
tected  and  blocked — although  the  short  TTL.  permits  rapid 
response  when  required.  With  only  4  instances  observed, 
this  behavior  is  currently  very  rare.  Nevertheless,  the  strat¬ 
egy  is  interesting  and  may  gam  popularity  among  malicious 


Figure  14:  Classified  FFx  I  JLArec  domain 

domain  owners  trying  to  evade  current  detection  technolo¬ 
gies,  warranting  future  research  into  the  detection  and  sub¬ 
version  of  these  domains. 

5. 4. 3  FF  domains 

Another  interesting  aspect  of  our  classifier  is  how  it  dis¬ 
tinguishes  between  the  various  FF  domains.  Recall  from  Ta¬ 
ble  4  that  FI  is  the  dominant  feature  for  SVM-4,  w  ith  the  NA 
rec  being  4x  as  influential  as  the  A  rce.  From  Table  2  and 
Fig.  3,  w'e  see  that  the  FF  domains  recruit  more  IPs  for  their 
A  recs  than  their  NA  recs,  making  the  A  recs  appear  more 
fluxy.  Therefore,  for  SVM-4,  behavior  that  isn't  considered 
fluxy  enough  tor  the  A  rec  could  be  sufficient  when  present 
in  the  NA  rec  The  consequence  of  this  asymmetric  weight¬ 
ing  of  fluxincss  can  be  w  itnessed  for  the  domains  in  F  ig.  1 3 
(classified  as  FFx2)  and  Fig.  14  (classified  as  FFxl  -NArec) 
Both  domains  demonstrate  definite  fluxy  behavior  in  one  of 
their  record  types:  Fig.  13  is  clearly  fluxy  in  the  A  rec,  w  hile 
Fig.  14  is  clearly  fluxy  in  the  NA  rce.  With  only  about  20  A 
rec  IPs,  the  recruitment  behavior  in  Fig.  14  resembles  that  of 
a  MAL  domain,  with  an  IP  overlap  of  less  than  4%.  Thus, 
the  classifier  has  performed  correctly:  a  domain  with  FF  be 
havior  in  its  NA  rce  and  MAL  behavior  in  its  A  rec  should  be 
considered  a  FFxl_NArec  domain.  However,  it  isn’t  imme¬ 
diately  obvious  why  Fig.  I  3  is  considered  fluxy  in  its  NA  rec, 
which  appears  relatively  stable.  Further  analysis  revealed 
that  the  domain  has  an  IP  overlap  of  ^26%,  corresponding 
with  the  ^20-30  NA  ree  IPs  demonstrating  fluxy  behavior. 
Since  the  fluxy  A  rec  contributes  over  of  the  NA  rcc  IPs. 
the  less  stringent  fluxincss  demands  for  the  NA  rec  arc  met, 
and  the  domain  is  correctly  classified  its  FFx2. 

5.4.4  Domain  Type  Distribution 

Table  5  shows  the  number  and  distribution  for  each  do¬ 
main  type  identified  by  our  classifier.  Of  the  106,31  I  do¬ 
mains  we  monitored,  our  rule-based  filter  (Section  5.3.1) 
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identified  101.142  domains  as  benign  or  lacking  in  sufficient 
data — corresponding  to  95. 14%  of  our  monitored  domains. 
This  is  reasonable,  considering  the  domains  monitored  were 
extracted  from  online  malware  and  phishing  repositories  or 
from  spam  emails.  Most  malicious  domains  are  only  active 
for  a  short  period  of  time  before  they  are  discovered  and 
blocked  DIGGER  would  have  collected  little-to-no  valid 
data  for  these  dead  domains,  and  they  would  have  been  fil¬ 
tered  out.  Also,  not  all  hyperlinks  in  spam  belong  to  mali¬ 
cious  or  phishing  websites;  some  contain  legitimate  links. 

After  filtering,  MAL  and  FF  domains  account  for  94.27% 
of  the  remaining  5,169  test  domains.  Since  the  domain  list 
is  generated  from  suspicious  sources,  it's  unlikely  that  any 
would  utilize  the  extensive  CDN  infrastructure  typically  em¬ 
ployed  by  popular  and  reputable  domains.  Of  the  4,873  ne¬ 
farious  domains,  ^96%  were  MAL  domains  and  179  were 
FF  domains  This  plethora  of  MAL  domains  results  from 
their  case  of  management  as  the  traditional  and  most  popu¬ 
lar  mechanism  employed  by  malicious  websites. 

The  additional  level  of  misdirection  and  the  nearly  lim¬ 
itless  supply  of  IPs  provided  by  botnets  make  FF  domains 
appealing,  despite  their  more  diligent  maintenance  require¬ 
ments  Thus  far,  it  has  been  primarily  FFxl_Arcc  domains 
observed  in  the  wild,  and  their  popularity  is  supported  with 
our  findings:  £=49%  of  the  FF  domains  are  FFxI-Arce  Un¬ 
fortunately  for  botmasters,  security  professionals  have  be¬ 
come  aware  of  the  FFxl_Arcc  botnet  technique,  devising 
clever  detection  strategics  While  botnets  provide  a  steady 
source  of  fresh  A  rec  IPs,  the  NScs  can  still  be  blocked, 
crippling  the  botmastcr’s  control  until  new  NScs  can  be  ac¬ 
quired.  In  an  apparent  attempt  by  botmasters  to  overcome 
this  limitation,  wc  w  itnessed  a  considerable  presence  of  FFx2 
domains,  composing  £=21%  of  the  FF  domains.  FFx2  do¬ 
mains  provide  further  misdirection  and  protection  for  lhe 
botmaster,  guarding  the  NScs  against  simple  countermea¬ 
sures  ai  the  expense  of  a  more  diligent  management  effort 
Interestingly  analysis  of  the  identified  FFx2  domains  re¬ 
vealed  a  spectrum  in  the  amount  of  NA  rec  fluxincss  in¬ 
corporated  by  botmasters.  Obviously,  wc  observed  domains 
that  were  incredibly  fluxy  in  both  record  types,  as  demon¬ 
strated  by  old-and-girl.com  (Fig.  3).  While  it’s  interesting 
to  observe  these  aggressive  FFx2  domains  in  the  wild,  it 
was  the  FFx2  domains  at  the  other  end  of  the  spectrum  that 
proved  more  insightful.  As  an  example,  recall  the  more 
modest  FFx2  domain  ehuytyt.cn  (Fig  13).  Writh  over  2.500 
unique  A  rec  IPs,  ehwtyt.cn  is  considerably  more  fluxy  in 
its  A  rec  than  its  NA  rcc.  By  using  bot  IPs  from  its  A  rec  for 
roughly  lA  of  its  NA  rec  IPs,  FFx2  domains  like  ehuytyt.cn 
benefit  from  the  increased  control  and  stability  provided  by 
traditional  NSes,  while  simultaneously  enhancing  the  do¬ 
main's  resilience  to  subversion — for  a  minimal  increase  in 
management— through  the  use  of  botnets. 

Another  interesting  discovery  is  the  apparent  popularity  of 
FFxl-NArcc  domains,  accounting  for  j^30%  of  the  total  FF 
domains  ohserved  Surpn singly,  this  is  a  larger  share  than 


Table  5:  Relative  distributions  of  the  various  domain  types 

the  FFx2  domains.  It  seems  that  botmasters  have  become 
aware  of  security  professionals  analyzing  domains'  A  recs 
for  FF  behav  ior.  Consequently,  they  have  migrated  the  fluxy 
behavior  to  the  NA  rcc,  where  it  is  less  likely  to  be  noticed 
Fig.  14  is  a  typical  example  of  the  FFx!_NArcc  domains 
identified  by  our  classifier.  It  demonstrates  a  MAL  domain 
strategy  for  its  A  rcc  IPs  and  a  FF  strategy  for  its  NA  rcc 
IPs.  This  results  in  the  domain  appearing  more  benign  when 
its  A  recs  are  analyzed,  while  providing  the  botmaster  with 
a  fine  level  of  control  over  the  NScs.  Should  the  domain's 
malicious  activity  be  detected  and  the  A  rcc  IPs  blocked, 
the  botmaster,  having  retained  control  over  the  NSes,  can 
replace  the  IPs  with  minimal  service  interruption.  The  inv 
plication  of  this  discovered  behavior  is  straightforward-  both 
record  types  must  be  monitored  for  fluxy  behavior  in  order 
to  quickly  identify  FF  domains  and  their  botnets  A  real 
time  monitor  analyzing  only  domains'  A  recs  w  ill  not  iden¬ 
tify  FFxl.NAree  domains  as  fluxy.  and  it  could  take  days 
for  the  A  rce's  MAI  domain  behavior  to  be  detected  How¬ 
ever,  monitoring  NA  recs  for  fluxy  behavior  could  Identify 
the  FF  domain  much  more  rapidly,  providing  a  quicker  re¬ 
sponse  time  for  mitigating  countermeasures. 


6.  LIMITATIONS  AND  FUTURE  WORK 

While  our  multi-leveled  classifier  has  proven  etYeclivc  in 
identifying  the  different  domain  types,  it  is  only  a  proof- 
of-concept  detector  It  is  temporally  naive,  operating  over 
the  complete  set  of  data  gathered  during  DIGGER'S  £=3.5- 
month  monitoring  period.  Moreover,  our  data  was  gathered 
by  240  nodes  dispersed  around  the  globe  While  this  might 
be  acceptable  for  a  classifier,  an  optimal  and  practical  real- 
limc  detector  should  function  over  a  much  shorter  duration, 
relying  on  fewer  nodes.  The  problem  of  determining  the  op¬ 
timal  monitoring  period  and  the  minimal  number  of  nodes  is 
part  of  our  future  work.  Our  classifier  can  also  suffer  from 
certain  anomalous  behavior,  such  as  IP  parking,  which,  if 
dominant,  can  cause  the  DNS  data  to  appear  benign  and  re¬ 
sult  in  misclassification.  This  problem  can  be  solved  with  an 
adaptive  classifier,  utilizing  incremental  training  lo  improve 
detection  in  real  time 

Another  potential  limitation  of  our  work  results  from  bot¬ 
nets  using  rapid,  automatic  generation  of  domain  names, 
such  as  Torptg  [20].  FF  domains  using  this  type  of  botnet 
will  automatically  change  their  domain  name  on  a  regular 
hasis,  making  it  difficult  to  form  a  long-term  picture  of  the 
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botnet’s  activities.  DIGGER  has  no  way  to  predict  the  future 
domain  names  these  botnets  might  utilize.  Consequently, 
our  picture  of  their  DNS  activity  will  be  incomplete;  we 
will  only  gather  DNS  data  on  such  domains  until  their  do¬ 
main  name  changes.  Since  DIGGER  continuously  updates 
the  list  of  suspicious  domains  it  monitors,  we  will  be  able 
to  gather  further  DNS  data  for  these  botnets  under  different 
domain  names.  Statistical  clustering  methods  hased  on  the 
observed  bot  IPs  could  help  by  associating  different  FF  do¬ 
mains  with  the  same  underlying  botnets.  However,  even  this 
solution  suffers  from  inconsistencies  introduced  by  DHCP 
chum,  warranting  further  research  into  this  problem.  Inci¬ 
dentally,  rapidly-and-automatically-changing  domain  names 
arc  typically  used  by  hots  as  a  mechanism  for  contacting 
their  C&C  server;  their  kaleidoscopic  nature  makes  them  ill- 
suited  for  phishing  or  malicious-content  campaigns,  which 
require  more  perststent  domain  names.  Since  the  focus  of 
this  paper  is  on  FF  botnets  perpetrating  such  seams,  we  sel¬ 
dom  encounter  the  sw  iftly-changing  domains  used  for  C&C. 

7.  CONCLUSION 

In  this  paper,  we  examined  the  global  IP-usagc  patterns 
exhibited  hy  different  types  of  malicious  and  benign  domains, 
including  FFxl  and  FFx2  domains.  We  have  deployed  DIG¬ 
GER,  a  lightweight  DNS-probing  engine,  on  240  Planet- 
Lab  nodes  spanning  4  continents.  Collecting  DNS  data  for 
over  3.5  months  on  a  plethora  of  domains,  our  global  van¬ 
tage  point  cnahlcd  us  to  identify  the  various  IP-usagc  pat¬ 
terns  inherent  to  the  operation  of  the  different  domain  types. 
Conducting  a  detailed  analysis,  we  were  able  to  determine 
distinguishing  behavioral  features  between  the  domain  types 
based  on  their  DNS-query  results.  We  have  quantified  these 
features  and  demonstrated  their  effectiveness  for  detection 
hy  building  a  proof-of-conccpt,  multi-leveled  SVM  classi¬ 
fier  capahlc  of  discriminating  between  five  domain  types: 
CDN,  non-CDN,  MAL,  FFx2,  FFxl^\rcc  and  FFxLNArec 
Applying  our  classifier  on  a  set  of  5,169  unknown  domains 
produced  promising  results,  correctly  categorizing  the  do 
mains  with  only  2  false  positives  due  to  DNS  IP  parking 
Our  classification  results  have  shown  the  relative  distribu¬ 
tion  of  the  domain  types  in  our  test  data  and  the  current  state 
of  FF  domains,  including  the  increased  presence  and  versa 
tile  implementation  range  of  FFx2  domains.  We  have  showm 
that  fiuxincss  is*  typically  more  pronounced  in  A  rccs.  and 
that  there  is  an  apparent  trend  towards  using  FFxLNArec 
domains,  which  were  previously  unseen  in  the  wild. 
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